---title: "Transcrição da Prova Teórica 1 — nome: " disciplina: "Gestão de Projetos de Software" codigo_disciplina: "GPS" avaliacao: "Prova Teórica 1" periodo: "2026-2" data: "2026-10-19" discente: nome: "Bianca da Silva Barros" matricula: "20223004410" curso: "Engenharia de Computação" turma: "Unidade Timóteo" nota_total: 16.8 nota_maxima: 25.0 legibilidade_percentual: 94 metadados_transcricao: transcritor: "Antigravity Assistant (Visão Computacional)" data_transcricao: "2026-10-19" grau_fidelidade: "Fiel (ipsis litteris), integrando continuação de rascunho e omissões" format: html: toc: true theme: cosmo pdf: documentclass: scrartcl papersize: a4 geometry: - margin=20mm --- # Transcrição da Prova Teórica 1 — Bianca da Silva Barros ## Questão 1 ### 1.1 (1,5) Projeto vs. operação — três características com evidências: O Professor Agente é um projeto, pois um intervalo de tempo, o semestre, está sendo dedicado para a construção de uma aplicação web, tendo início, meio e fim. ### 1.2 (2,0) Duas alternativas de trade-off sem sacrificar qualidade + impacto no Triângulo de Ferro: I. A primeira alternativa seria analisar quais funcionalidades são mais relevantes para a solução e quais podem ser tratadas com menos prioridade no status atual. Dessa forma, seria necessário reorganizar o tempo e escopo. ### 1.3 (1,5) Ciclo de vida e justificativa (preditiva, ágil ou híbrida): Híbrida, pois embora tenha um prazo final, a data de entrega dos milestones sofre adiamentos conforme as necessidades que surgem. --- ## Questão 2 ### 2.1 (1,5) EAP de dois níveis (substantivos, regra dos 100%, $\ge 3$ pacotes de trabalho): ``` [Espaço para desenho/diagrama da EAP] Assistente | +----------------------+--------------------+--------------------+ | | | | Login/Inter. de Chat Integração com LLM Histórico conversas Dashboard Prof. - Arquitetura - System Prompt Relatórios - Backend (BD+API) - Casos de teste - Frontend - Implementação da API ``` É hierárquica e orientada a entregas para que haja um controle das funcionalidades que estão sendo entregues. ### 2.2 (1,5) Issue completa (título, descrição, critério, estimativa/estratégia) e 2ª Issue com justificativa relativa: 1. Arquitetura da tela de Login Fazer o protótipo inicial da interface de login do Usuário, onde ele poderá realizar o cadastro e login na sua conta. Critérios: 1. protótipo interativo 2. Tela de Cadastro (email, user, senha) 3. Tela de Login (user, senha) Estimativa: 3 horas (((continuei na folha de rascunho))) *[Continuação na página 6 — Espaço de Rascunho]:* 2.2) API de Login Criar o banco de dados com as informações de Login e fazer a API de integração. Estimativa: 5 horas. A estratégia utilizada foi levando em consideração o tempo necessário gasto em atividades similares anteriores. ### 2.3 (2,0) Milestones vs. Sprints + contexto para Kanban sem Sprints: [NÃO RESPONDEU / EM BRANCO] --- ## Questão 3 ### 3.1 (1,5) DoD, relação com pipeline CI/CD e omissão de testes de segurança: DoD são as condições de qualidade necessárias para a entrega de qualquer tarefa da solução. O CI/CD descrito faz parte dessas condições, e sem ele a tarefa não é indicada como finalizada. ### 3.2 (1,5) CoQ — classificar (a), (b), (c), (d) + custo mais alto: a) prevenção b) avaliação c) falha externa d) falha interna A falha externa tende ser a mais cara, pois demanda mais recursos resolver um erro em uma solução já em produção. ### 3.3 (2,0) Heurística 1:10:100, limites em IA e uso como argumento qualitativo: A regra determina que o custo de solucionar problemas na solução tende a ser ordinal: 1 - Encontrar o erro na fase de prevenção 10 - Fase de desenvolvimento 100 - Solução já em Produção. Por isso, a fase de prevenção, com testes e avaliação, é importante, pois tende a ser mais barato e ter um risco operacional menor encontrar e solucionar erros nessa fase. --- ## Questão 4 ### 4.1 (1,5) Risco vs. problema (Cap. 6) + quadrante na matriz $P \times I$ e estratégia de resposta: Foi um problema pois já aconteceu e precisa ser solucionado. Quadrante Crítico. ### 4.2 (1,5) Três ações imediatas + uma ação preventiva (defesa em profundidade): I. Privar o repositório II. Trocar a chave III. Apagar o commit. Prevenção: Implementar testes automatizados em um pipeline, bloqueando a publicação caso contenha a chave. ### 4.3 (2,0) Risco de entrada modelado (causa, P, I, mitigação, contingência) + mitigação de saída + artefato de documentação: - Entrada: • prompt malicioso que tenta burlar as condições do System Prompt • probabilidade: médio • impacto: baixo • mitigação: testes e avaliações • contingência: System Prompt - Saída: • resposta contendo a solução completa • impacto: crítico • probabilidade: média • mitigação: testes --- ## Questão 5 ### 5.1 (1,5) Comunicação síncrona vs. assíncrona no GitLab + prática/ritual de registro de decisões: - Síncrona: • vantagem: definição formal das soluções. Frequência definida. • desvantagem: mais burocracia - Assíncrona: • vantagem: mais rápido e prático • desvantagem: perder o registro das mensagens. Realizar dailys e code reviews, e manter um chat para dúvidas recorrentes. ### 5.2 (1,5) Matriz Poder $\times$ Interesse dos 5 stakeholders, premissas e estratégia de comunicação: 1. Manter Informado 2. Manter Satisfeito 3. Gerenciar de Perto (4) monitorar (2) Gerenciar de perto -> reuniões online ou presenciais no início e final do desenvolvimento de cada entrega. ### 5.3 (2,0) Conflito pedagógico vs. técnico — Thomas-Kilmann (1 escolha justificada + 2 inadequadas): [NÃO RESPONDEU / EM BRANCO]